[00:01.020 --> 00:04.340]  Welcome, everyone, to the Crypto and Privacy Village.
[00:04.840 --> 00:08.400]  This is our seventh year and DEF CON 28 here in safe mode.
[00:08.400 --> 00:10.620]  I am Haim Cohen. I'm one of the hosts here.
[00:11.200 --> 00:13.120]  Let's just get some stuff out of the way.
[00:13.120 --> 00:14.700]  You can join us at Discord.
[00:15.800 --> 00:18.800]  You can find us there. We have a couple channels.
[00:19.080 --> 00:22.020]  The gold bug just opened up,
[00:22.020 --> 00:24.320]  so if you're interested in the gold bug puzzle,
[00:24.320 --> 00:25.840]  we did that very well.
[00:28.940 --> 00:32.300]  And let's just introduce our first speaker,
[00:32.300 --> 00:34.940]  Hanno Berg, and he's going to go.
[00:36.000 --> 00:37.340]  Yeah, hi.
[00:37.920 --> 00:40.000]  Let's switch these slides.
[00:42.480 --> 00:45.180]  Okay, you can go full screen and you can go.
[00:49.440 --> 00:51.460]  Okay, do you see the slides?
[00:51.580 --> 00:53.020]  I see them.
[00:53.200 --> 00:54.840]  Yeah, okay, great.
[00:54.840 --> 00:57.220]  Yeah, hello.
[00:57.220 --> 01:00.720]  So I'm Hanno and I'm going to talk about
[01:00.720 --> 01:02.640]  StartTLS today.
[01:04.590 --> 01:07.040]  This is some research that I've been doing
[01:07.040 --> 01:10.480]  together with Damian Hodebniak, Fabian Ising
[01:10.480 --> 01:12.340]  and Sebastian Schinzel.
[01:12.340 --> 01:16.980]  And we are soon going to publish a paper on this.
[01:17.420 --> 01:19.420]  Yeah, we kind of figured out that
[01:19.420 --> 01:23.460]  StartTLS seems to not be very well
[01:23.460 --> 01:26.940]  researched and it has some issues that are not very well known
[01:26.940 --> 01:29.720]  and we looked a bit deeper into this.
[01:32.100 --> 01:33.120]  So,
[01:33.120 --> 01:35.880]  from the general idea, I guess most people are
[01:35.880 --> 01:38.140]  roughly aware what StartTLS is, but
[01:38.140 --> 01:41.440]  if we talk about TLS connections, there's
[01:41.440 --> 01:44.200]  two ways to do a TLS connection.
[01:45.260 --> 01:47.520]  One way is that we have an extra
[01:47.520 --> 01:50.420]  port for the encrypted version of protocol
[01:50.420 --> 01:53.840]  where we directly start a TLS connection
[01:53.840 --> 01:56.440]  on that port. And this is called
[01:56.440 --> 01:59.420]  implicit TLS because we
[01:59.420 --> 02:02.200]  kind of implicitly are using TLS
[02:02.200 --> 02:05.780]  based on the port number. We already know that this is an encrypted
[02:05.780 --> 02:08.700]  connection. And then there's this other way
[02:08.700 --> 02:11.560]  which is StartTLS where we start with some
[02:11.560 --> 02:14.660]  protocol that is not encrypted and then we
[02:14.660 --> 02:17.800]  have some special command which is usually StartTLS
[02:17.800 --> 02:21.040]  command that upgrades
[02:21.040 --> 02:23.780]  this connection to be encrypted.
[02:25.080 --> 02:26.920]  And in the web
[02:26.920 --> 02:29.660]  we are only using implicit TLS
[02:29.660 --> 02:33.040]  basically. So what we usually do is that we have
[02:33.040 --> 02:36.080]  HTTPS which is kind of its own protocol
[02:36.080 --> 02:38.440]  on its own port which is
[02:38.440 --> 02:42.920]  HTTP protocol with a TLS wrapped around it.
[02:44.400 --> 02:44.800]  But
[02:44.800 --> 02:47.820]  StartTLS, the most common usage is
[02:47.820 --> 02:50.140]  in the context of emails.
[02:52.320 --> 02:52.900]  And
[02:53.560 --> 02:56.900]  in this talk I am mostly going to talk
[02:56.900 --> 03:00.560]  about the connection between an email client and the server.
[03:00.560 --> 03:02.880]  I will talk a bit about server to
[03:02.880 --> 03:05.060]  server connections later but also
[03:05.800 --> 03:09.280]  we haven't focused so much on this because this is kind of
[03:10.600 --> 03:12.160]  a different issue because
[03:12.160 --> 03:15.340]  the considerations for server to server are
[03:15.340 --> 03:18.040]  quite different than from client to server.
[03:19.880 --> 03:21.260]  So all email
[03:21.260 --> 03:24.340]  protocols we use, I guess you are aware
[03:24.340 --> 03:27.420]  of that, we have SMTP, POP3 and IMAP.
[03:27.420 --> 03:30.240]  We use SMTP to send emails, POP3 to
[03:30.240 --> 03:32.940]  fetch emails or IMAP also kind of to fetch
[03:32.940 --> 03:36.260]  emails but also to manage a mailbox on the
[03:36.260 --> 03:39.740]  server. All of these protocols support StartTLS.
[03:39.740 --> 03:43.020]  And for the client to server communication
[03:43.420 --> 03:46.120]  these protocols also all support
[03:46.120 --> 03:49.420]  implicit TLS. So we kind of, as a user
[03:49.420 --> 03:52.380]  we can choose which one we use. So if
[03:52.380 --> 03:55.160]  we can choose between the two then the obvious question is
[03:55.160 --> 03:58.680]  which one is better and which one is more secure.
[04:00.940 --> 04:01.580]  So
[04:01.580 --> 04:03.740]  how does this StartTLS
[04:04.280 --> 04:07.280]  work? So these email
[04:07.280 --> 04:10.380]  protocols, they are all kind of relatively simple
[04:10.380 --> 04:12.700]  text protocols. So it's a line-based
[04:13.840 --> 04:16.560]  protocol where a client sends a
[04:16.560 --> 04:19.320]  command to a server and gets some kind of answer. So
[04:19.860 --> 04:23.600]  this is an SMTP session here.
[04:23.600 --> 04:25.580]  The S and C at the beginning
[04:25.580 --> 04:28.540]  that is server and client. So
[04:28.540 --> 04:31.480]  if you connect to an SMTP server, the first thing
[04:31.480 --> 04:34.400]  is the server sends this line which
[04:34.400 --> 04:37.360]  is basically a hello message which contains its
[04:37.360 --> 04:39.920]  host name and a special
[04:41.260 --> 04:43.640]  code number. And
[04:43.640 --> 04:46.580]  then you send this elo command that is basically
[04:46.580 --> 04:49.560]  from the client, always the first command which is kind of
[04:49.560 --> 04:52.520]  introducing the client. And then the server usually
[04:52.520 --> 04:55.670]  gets back with a list of features that the server supports.
[04:56.280 --> 04:58.400]  And here you can see in this list
[04:59.440 --> 05:01.420]  that it ends with this
[05:01.420 --> 05:04.440]  250 star TLS which means
[05:04.440 --> 05:07.560]  okay, the server just told us that it supports
[05:07.560 --> 05:10.620]  star TLS. And then the client can
[05:10.620 --> 05:13.820]  use this star TLS. This is simply a
[05:13.820 --> 05:16.700]  text command. It gives them this command
[05:16.700 --> 05:20.440]  star TLS. Then the server answers with
[05:20.440 --> 05:22.860]  a 220 code which means everything is
[05:22.860 --> 05:25.960]  all right. And the okay behind that
[05:25.960 --> 05:28.600]  is basically meaningless. That's more or less like a comment.
[05:29.760 --> 05:32.720]  And then we do a handshake. And for the
[05:32.720 --> 05:35.560]  colors here, the gray thing is
[05:35.560 --> 05:38.700]  the plain text part of the protocol. And
[05:38.700 --> 05:41.120]  then we have a TLS handshake. And the green
[05:41.120 --> 05:44.620]  thing here, that is then encrypted and authenticated
[05:44.620 --> 05:47.500]  with all the properties that we usually
[05:47.500 --> 05:50.560]  expect from a TLS connection. So we expect that there's
[05:51.160 --> 05:53.460]  some sense of security here
[05:53.460 --> 05:56.440]  while the thing at the beginning, it's plain text. So
[05:56.440 --> 05:59.700]  an attacker can read it, an attacker can manipulate it.
[06:00.200 --> 06:02.540]  And then basically we start over because
[06:02.540 --> 06:05.740]  kind of all the information we got before the TLS
[06:05.740 --> 06:08.760]  handshake, we don't really trust it. So we send this
[06:08.760 --> 06:12.160]  elo command again. And then maybe we can do a
[06:12.160 --> 06:14.960]  login and send an email. And you
[06:14.960 --> 06:18.080]  don't need to understand the details of how the protocol
[06:18.080 --> 06:21.100]  works. But the basic idea just that should stick here is
[06:21.220 --> 06:23.840]  we have a plain text protocol. We have a command that
[06:23.840 --> 06:26.780]  starts a TLS connection. Then we do a handshake and
[06:26.780 --> 06:29.480]  then we kind of move this protocol into TLS.
[06:31.560 --> 06:33.000]  Now, first, something
[06:33.000 --> 06:35.960]  which is obvious, that if you use
[06:35.960 --> 06:38.880]  start TLS in an opportunistic way,
[06:38.880 --> 06:40.400]  this is insecure. So
[06:41.880 --> 06:44.180]  there is some email clients
[06:44.860 --> 06:48.020]  implement start TLS in a way where they will say,
[06:48.020 --> 06:51.240]  okay, if the server offers start TLS,
[06:51.240 --> 06:55.040]  then I will use it. And if the server does not offer it,
[06:55.040 --> 06:57.820]  then I will just stay in plain text mode.
[06:58.440 --> 07:00.560]  So we will use start TLS
[07:00.560 --> 07:04.040]  if we can, but if not, then we will just do plain text.
[07:04.360 --> 07:07.520]  And a
[07:07.520 --> 07:11.720]  network attacker can attack this.
[07:11.720 --> 07:12.660]  We figured out that
[07:12.660 --> 07:15.660]  this is actually not that common anymore. This used to
[07:15.660 --> 07:18.060]  be the case maybe 10 years ago, but
[07:18.060 --> 07:21.660]  today most clients don't really do this anymore.
[07:21.920 --> 07:24.200]  And it's obvious that an attacker can
[07:24.200 --> 07:26.820]  in such a scenario, an attacker can just
[07:27.400 --> 07:30.420]  they can pretend to be the server and then they can say,
[07:30.420 --> 07:33.020]  yeah, I don't support start TLS and then
[07:33.020 --> 07:36.500]  the client logs in and then the attacker knows the username
[07:36.500 --> 07:39.020]  and password. So that is obviously
[07:39.020 --> 07:42.120]  insecure, but that's not really
[07:42.120 --> 07:44.320]  what our research was about because
[07:44.320 --> 07:47.420]  that's, yeah.
[07:49.840 --> 07:50.620]  Yeah.
[07:50.620 --> 07:53.360]  But this turns out to be not the only
[07:53.360 --> 07:56.520]  security problem with start TLS. So you could think, okay,
[07:56.520 --> 07:59.460]  this is a problem, but if we implement a client in a way
[07:59.460 --> 08:02.580]  that it always forces this start TLS connection
[08:02.580 --> 08:05.940]  and will just refuse to connect if it cannot do that,
[08:05.940 --> 08:08.540]  then this is secure. But it turns out that this is
[08:08.540 --> 08:09.660]  not the case.
[08:11.800 --> 08:14.020]  So if you look at what start TLS
[08:14.020 --> 08:17.500]  is, then it's kind of a form of state transition
[08:17.500 --> 08:21.040]  where you have the protocol, which can be in two states.
[08:21.040 --> 08:23.740]  It can be in a plain text state and
[08:23.740 --> 08:26.860]  in an encrypted state after the TLS handshake.
[08:29.860 --> 08:30.820]  And this
[08:30.820 --> 08:33.980]  raises quite a few questions.
[08:34.800 --> 08:36.820]  So at first you can ask, okay,
[08:36.820 --> 08:40.140]  we have the state transition,
[08:40.140 --> 08:42.820]  but which protocol features can we use before
[08:42.820 --> 08:45.900]  we turn the encryption on? What can
[08:45.900 --> 08:49.200]  happen in the plain text part? And also
[08:49.200 --> 08:51.740]  how should we treat the data that
[08:51.740 --> 08:55.100]  we got before the handshake, for example, server features
[08:55.100 --> 08:58.160]  or if there's any login, because we cannot
[08:58.160 --> 09:00.820]  really trust that data as it's
[09:02.920 --> 09:04.800]  obviously not secured.
[09:04.800 --> 09:08.500]  And also you could ask, do the implementations,
[09:08.500 --> 09:11.160]  do they have a clear understanding what is encrypted
[09:11.160 --> 09:14.020]  and not encrypted? And do they clearly
[09:14.020 --> 09:15.540]  separate that?
[09:17.820 --> 09:20.100]  So just one example, which is
[09:20.440 --> 09:23.120]  a relatively obvious problem, the IMAP protocol
[09:23.120 --> 09:25.960]  has a feature which is called alerts,
[09:25.960 --> 09:29.140]  which is basically the server sends a message to the client
[09:29.140 --> 09:32.140]  and the client is supposed to show this to the user.
[09:32.140 --> 09:35.220]  And these alerts, it turns out, they can be sent at any
[09:35.220 --> 09:38.580]  time. So they can be sent in the plain text
[09:38.580 --> 09:41.180]  part, which is
[09:41.180 --> 09:44.100]  interesting because this is a screenshot from
[09:44.100 --> 09:47.560]  Outlook where the
[09:47.560 --> 09:50.500]  IMAP server sends a message to the user and this
[09:50.500 --> 09:53.080]  message is not secure. It is
[09:53.760 --> 09:56.040]  sent in plain text, even though the
[09:56.040 --> 09:59.640]  mail client is configured to use a secure connection.
[09:59.640 --> 10:02.620]  And here you can even see, you can even include a link
[10:02.620 --> 10:05.700]  which will be highlighted. So we have here,
[10:05.700 --> 10:08.580]  your IMAP server wants to alert you
[10:08.580 --> 10:11.260]  to the following, please download my post something something
[10:11.260 --> 10:14.540]  and then the attacker can put in a link where he provides
[10:14.720 --> 10:17.980]  a malicious file. So we have an alert sent in plain text
[10:17.980 --> 10:20.600]  but to the user it looks like this is a legitimate
[10:20.600 --> 10:23.460]  message from his mail server. So he may
[10:23.960 --> 10:25.660]  want to trust it.
[10:25.660 --> 10:28.840]  So yeah, this is just a design
[10:28.840 --> 10:32.360]  problem of the protocol, how it is specified.
[10:34.740 --> 10:37.760]  But then we came upon the issue
[10:37.760 --> 10:41.000]  of buffering bugs. And this is something that
[10:41.000 --> 10:42.900]  has been known for a while.
[10:43.920 --> 10:46.340]  And the question here is really, is
[10:46.340 --> 10:49.540]  something part of the TLS session or not? And do
[10:49.540 --> 10:52.360]  clients and servers have a good idea about this?
[10:53.620 --> 10:55.320]  So there was a vulnerability
[10:55.320 --> 10:58.980]  in 2011 already, so this is nine years
[10:58.980 --> 11:01.840]  ago, which was named
[11:01.840 --> 11:04.960]  plain text command ejection in multiple implementations of
[11:04.960 --> 11:07.600]  star TLS. This was discovered by the author of
[11:07.600 --> 11:10.460]  Postfix. And
[11:11.460 --> 11:13.660]  what happened here is, like if we look
[11:13.660 --> 11:16.640]  again at this star TLS connection and
[11:16.640 --> 11:19.720]  this is like only the, I've shortened this a bit, I've
[11:19.720 --> 11:22.820]  cut away the stuff that currently doesn't matter,
[11:22.820 --> 11:25.700]  like we have this client sends the star
[11:25.700 --> 11:28.680]  TLS command, gets an answer from the server and then there's
[11:28.820 --> 11:31.820]  a handshake happening. Now, what
[11:31.820 --> 11:34.920]  can happen if we do something like this, where a client
[11:34.920 --> 11:38.080]  sends the star TLS command and
[11:38.080 --> 11:40.380]  then sends something else in plain text
[11:41.300 --> 11:43.860]  and then gets the answer
[11:43.860 --> 11:46.800]  from the server that he can now start the TLS handshake
[11:46.800 --> 11:50.040]  and then they do the TLS handshake. So it turns out
[11:50.040 --> 11:53.140]  that there are quite a few implementations of servers
[11:53.140 --> 11:55.800]  that will then process
[11:56.340 --> 11:59.260]  both of these commands, the star TLS and the
[11:59.260 --> 12:02.180]  whatever other command you sent together
[12:02.180 --> 12:05.280]  with the star TLS in a single TCP packet.
[12:06.480 --> 12:07.480]  That it will
[12:07.480 --> 12:11.140]  put this in some kind of buffer and process every command
[12:11.140 --> 12:13.700]  after another and then it will answer to this
[12:14.300 --> 12:17.580]  command that was appended to the star TLS
[12:17.580 --> 12:21.080]  in the TLS session. So we kind of have something
[12:21.080 --> 12:24.200]  here that traverses from the plain text part of the
[12:24.200 --> 12:27.120]  protocol to the TLS part of the protocol.
[12:27.180 --> 12:29.660]  Like we send something in plain text but the server
[12:29.660 --> 12:32.960]  kind of thinks that this is part
[12:32.960 --> 12:34.560]  of the TLS connection.
[12:36.900 --> 12:37.900]  Yeah, so
[12:39.420 --> 12:41.620]  that's basically what I just said.
[12:43.160 --> 12:46.260]  So this bug was originally found in Postfix
[12:46.260 --> 12:49.240]  but it turned out it affected multiple mail servers
[12:49.240 --> 12:52.220]  including Cyrus, Courier, Qmail
[12:52.220 --> 12:55.100]  and various proprietary mail stacks.
[12:55.100 --> 12:58.320]  So there's an advisory by
[12:58.320 --> 13:01.360]  US CERT from that time which contains a long list of
[13:01.360 --> 13:04.120]  affected servers. So this turned out to be a very
[13:04.120 --> 13:05.900]  widespread problem.
[13:06.880 --> 13:10.020]  Now you may wonder how you can attack this and this is
[13:10.020 --> 13:12.780]  kind of, I think this is maybe part of the reason why this
[13:12.780 --> 13:15.960]  bug is not very well known because the Postfix
[13:15.960 --> 13:18.880]  authors, they have described very well what
[13:18.880 --> 13:21.580]  the problem is but they haven't really
[13:21.580 --> 13:25.080]  published any exploit or explained how you could actually
[13:25.080 --> 13:27.280]  attack this. So it was kind of seen by
[13:28.020 --> 13:30.200]  and there was some
[13:30.820 --> 13:33.920]  email discussions from mail server developers where people were
[13:33.920 --> 13:36.780]  like, yeah, this is kind of a weird behavior but it's not really
[13:36.900 --> 13:39.860]  a security problem. But you can actually
[13:39.860 --> 13:41.820]  attack this pretty easily and
[13:43.500 --> 13:44.920]  this takes a bit of
[13:45.660 --> 13:47.340]  thinking what's going on here but
[13:48.060 --> 13:51.720]  so this is the first part
[13:51.720 --> 13:54.740]  of the attack which is we start a connection
[13:54.740 --> 13:57.520]  that is in plain text. So we have again
[13:57.520 --> 14:00.160]  this start message
[14:00.780 --> 14:03.520]  that's not really the interesting part. The interesting part begins
[14:03.520 --> 14:06.460]  where we have the start TLS and then this red
[14:06.460 --> 14:09.660]  stuff, this is injected by an attacker.
[14:09.660 --> 14:12.040]  So the attacker is injecting here another
[14:12.040 --> 14:15.480]  elo command which is, that is just always the first command
[14:15.480 --> 14:19.260]  that comes after start TLS. That's why we have to send that.
[14:19.320 --> 14:21.460]  And then the attacker locks in with its own
[14:21.460 --> 14:24.620]  credentials. So our assumption here is the attacker also
[14:24.620 --> 14:27.760]  has an account on this mail server but it could be something
[14:27.760 --> 14:30.620]  like a public email provider
[14:30.620 --> 14:33.500]  address. So that is a plausible assumption. And then
[14:33.500 --> 14:36.480]  the attacker is starting to send an email like
[14:37.620 --> 14:39.780]  he's setting a from address and a to
[14:39.780 --> 14:42.680]  address and the to address particularly is his own address
[14:42.680 --> 14:45.560]  and then it sends this data command which is basically
[14:45.560 --> 14:47.740]  now the email content starts.
[14:49.360 --> 14:51.860]  And then we get an answer
[14:51.860 --> 14:54.740]  from the server. This is now the answer to the start TLS
[14:54.740 --> 14:57.820]  command. So now we're doing a TLS handshake
[14:57.820 --> 15:01.580]  the client and the server but we have these injected commands.
[15:03.200 --> 15:03.560]  And then
[15:04.960 --> 15:06.740]  the server will answer to these
[15:06.740 --> 15:09.840]  injected commands. So it will send this normal greeting that always
[15:09.840 --> 15:12.700]  comes after the elo command and then it will
[15:12.700 --> 15:15.640]  authenticate the user and then it will say
[15:15.640 --> 15:18.980]  okay now the email starts. And now what happens
[15:18.980 --> 15:21.940]  is that the client doesn't know
[15:21.940 --> 15:24.860]  about any of this. It doesn't read from the server because
[15:24.860 --> 15:27.720]  it doesn't expect it to send anything. It sends its own
[15:27.720 --> 15:30.200]  elo command, it authenticates
[15:30.800 --> 15:33.980]  and then it starts sending a mail. Now what happens
[15:33.980 --> 15:36.740]  is that all this stuff, all this blue stuff
[15:36.740 --> 15:39.920]  which the client sends, this ends up being part
[15:39.920 --> 15:42.800]  of this email that we started sending
[15:42.800 --> 15:45.980]  to ourselves as an attacker. So the attacker
[15:45.980 --> 15:49.160]  now gets an email and that contains the
[15:49.160 --> 15:53.000]  authentication data from the victim,
[15:53.860 --> 15:56.440]  so this is a pretty severe attack.
[15:56.440 --> 15:59.160]  Like if you're a network attacker and we have a server vulnerable
[15:59.160 --> 16:02.020]  to this, we can force the client to send
[16:02.020 --> 16:04.480]  his credentials to us.
[16:07.260 --> 16:10.180]  There's a similar attack with IMAP that is
[16:10.520 --> 16:13.300]  a bit more tricky because like you can, in IMAP
[16:13.300 --> 16:16.400]  you can kind of store a mail into a mailbox and then
[16:16.400 --> 16:19.240]  it's the same idea. One problem with that
[16:19.240 --> 16:22.180]  was that in order to do that you need to know the exact
[16:22.180 --> 16:24.980]  size of the message that's going to come.
[16:25.120 --> 16:28.220]  That means you kind of need to guess how long
[16:28.220 --> 16:31.160]  the password of the user is, but you may be
[16:31.160 --> 16:33.820]  able to see that with a side channel attack and also
[16:33.820 --> 16:37.140]  it turns out that many mail servers on failed login
[16:37.140 --> 16:40.080]  attempts, they will just try to reconnect. So you have kind of
[16:40.080 --> 16:43.300]  as an attacker, you have multiple tries to do this
[16:43.300 --> 16:46.060]  so it's still a feasible attack. But it is
[16:46.480 --> 16:49.040]  a bit more difficult than the SMTP attack.
[16:51.180 --> 16:53.740]  Okay, so this bug was discovered
[16:53.740 --> 16:56.760]  in 2011. So you would hope
[16:56.760 --> 16:59.980]  that people have fixed this, but as probably
[16:59.980 --> 17:02.540]  no one is surprised, it's actually not
[17:02.540 --> 17:06.140]  fixed everywhere. So we did some scans
[17:06.140 --> 17:08.860]  and we found out that, yeah, in SMTP servers
[17:08.860 --> 17:11.220]  1.5% are vulnerable.
[17:12.920 --> 17:14.660]  In IMAP and POP3
[17:14.660 --> 17:17.040]  it's more, it's around 2.5%.
[17:18.360 --> 17:21.100]  I guess the reason why this is different is
[17:21.100 --> 17:23.980]  because this was originally described in an SMTP
[17:23.980 --> 17:27.360]  server, so that's probably where people had it on the radar.
[17:27.620 --> 17:30.140]  But the very same class of
[17:30.140 --> 17:33.240]  bug can happen in basically every protocol that supports
[17:33.240 --> 17:36.180]  StarTLS. Although I have
[17:36.180 --> 17:38.200]  to say for POP3, we
[17:38.840 --> 17:42.220]  didn't really find an exploit to attack
[17:42.220 --> 17:45.760]  this, but it's still kind of something that should be fixed.
[17:48.580 --> 17:51.020]  Now there's another question you can ask
[17:51.020 --> 17:53.680]  and that is, can we have the same
[17:53.680 --> 17:57.060]  kind of bug, but the other way around?
[17:57.060 --> 17:59.640]  That is, on the client side.
[17:59.880 --> 18:02.980]  So can we confuse the client to get data
[18:02.980 --> 18:06.740]  that was sent in plain text and the client thinks it's TLS data?
[18:07.280 --> 18:09.340]  And in turns out, yes, we can do that.
[18:09.340 --> 18:12.000]  So the idea is pretty much the same. The client
[18:12.000 --> 18:14.780]  sends a StarTLS command, then the server sends this
[18:14.780 --> 18:17.780]  220 code, which is kind of the
[18:17.780 --> 18:21.040]  just approving that, yeah, I got the StarTLS, now we can do
[18:21.040 --> 18:23.040]  TLS. And then
[18:23.780 --> 18:26.880]  we can append additional data that's coming from the server
[18:26.880 --> 18:30.040]  and then the client will interpret that as part of the TLS
[18:30.040 --> 18:32.900]  session. So yes, this attack
[18:32.900 --> 18:35.780]  also, this vulnerability also exists
[18:35.780 --> 18:37.220]  on the client side.
[18:40.860 --> 18:41.900]  So clients
[18:41.900 --> 18:44.820]  can be vulnerable to the same class of bug and we have
[18:44.820 --> 18:47.840]  called this a response injection because the other thing was
[18:47.840 --> 18:51.100]  called a command injection and here we call it a response injection.
[18:54.380 --> 18:57.040]  This is not that severe, but for example
[18:57.040 --> 18:59.920]  it can be used by an attacker to spoof
[18:59.920 --> 19:02.800]  mailbox content. You kind of have to guess
[19:02.800 --> 19:05.700]  what commands the client will send, but if you know
[19:05.700 --> 19:08.740]  which mail client it is, you can usually know that.
[19:08.740 --> 19:11.800]  So for example, you can show the user an
[19:11.800 --> 19:14.820]  IMAP inbox that is not his own and that contains
[19:14.820 --> 19:15.900]  other data.
[19:17.920 --> 19:20.820]  So it's still an issue.
[19:21.040 --> 19:23.320]  And the really
[19:23.960 --> 19:26.760]  surprising thing was that more than half of the mail clients
[19:26.760 --> 19:29.900]  that we tested were vulnerable to this bug. So this is a very
[19:29.900 --> 19:31.480]  very widespread issue.
[19:34.720 --> 19:35.960]  So to sum
[19:35.960 --> 19:39.040]  that up a bit, this DartTLS command injection, it was
[19:39.040 --> 19:41.780]  discovered in 2011 and it affected multiple
[19:42.720 --> 19:45.220]  implementations and even though many
[19:45.220 --> 19:47.700]  implementations were found back then, they are still
[19:47.700 --> 19:51.320]  widely used vulnerable implementations.
[19:53.540 --> 19:54.380]  Also,
[19:54.380 --> 19:57.140]  the same bug class exists on the client and the
[19:57.140 --> 19:59.340]  majority of implementations are vulnerable
[19:59.960 --> 20:03.400]  or were until we have reported it to them.
[20:05.760 --> 20:07.840]  And just very generally,
[20:07.840 --> 20:10.660]  if you're doing an implementation of DartTLS
[20:10.660 --> 20:13.460]  and you're not aware of this bug and you're doing a naive
[20:13.460 --> 20:16.600]  implementation, then you will have some kind of command
[20:16.600 --> 20:19.580]  buffer where you read the commands line by line
[20:19.580 --> 20:23.160]  and then you will usually have this bug too.
[20:23.240 --> 20:25.820]  So it's kind of one of these things where
[20:25.820 --> 20:28.960]  you have to actively be aware of this bug in order to
[20:28.960 --> 20:30.140]  prevent it.
[20:32.220 --> 20:34.340]  And this, in my
[20:34.340 --> 20:37.520]  opinion, is a clear sign that
[20:37.520 --> 20:40.340]  this is not something where we should say
[20:40.340 --> 20:43.760]  this is a flaw in the mail client, but this is a systemic
[20:43.760 --> 20:46.720]  problem in the standard. Like if you have a situation
[20:46.720 --> 20:49.800]  where the same bug appears again and again and
[20:49.800 --> 20:53.280]  again and in multiple different implementations,
[20:53.280 --> 20:55.180]  then you should wonder
[20:55.180 --> 20:58.660]  if this is something where we can
[20:59.480 --> 21:02.820]  just... if we can do better on the level of the standard
[21:02.820 --> 21:05.680]  and not say it's the flaw of the
[21:05.680 --> 21:07.280]  implementations.
[21:09.440 --> 21:10.760]  Yeah.
[21:11.560 --> 21:14.300]  There's more issues with DartTLS.
[21:16.040 --> 21:17.900]  One, the IMAP
[21:17.900 --> 21:20.900]  protocol has a feature which is called
[21:20.900 --> 21:24.280]  pre-auth. The idea here is
[21:24.280 --> 21:28.640]  that an IMAP server can,
[21:28.640 --> 21:32.860]  send a line which basically tells
[21:32.860 --> 21:36.040]  the client you're already logged in, you don't have to
[21:36.040 --> 21:37.260]  authenticate.
[21:38.540 --> 21:41.320]  So the idea here is, for example, if you have a controlled
[21:41.320 --> 21:44.820]  network where you do authentication based on IP
[21:44.820 --> 21:47.780]  addresses, maybe then you can say, okay, if a connection
[21:47.780 --> 21:50.880]  comes from this IP address, then we just assume
[21:50.880 --> 21:53.880]  that this is already authenticated and the user is
[21:53.880 --> 21:55.200]  already logged in.
[21:55.200 --> 21:59.160]  So now, DartTLS,
[21:59.160 --> 22:01.900]  the standard clearly says that it must not be performed
[22:01.900 --> 22:03.960]  in an authenticated state.
[22:04.920 --> 22:08.480]  So if we take these two things together,
[22:08.480 --> 22:11.220]  like we have a feature, DartTLS,
[22:11.220 --> 22:13.980]  that you must not use when in an authenticated
[22:13.980 --> 22:16.980]  state, but the server answers with this pre-auth line
[22:16.980 --> 22:20.120]  which says you are already authenticated.
[22:20.280 --> 22:23.060]  Now, what should a client do? Like we have a client
[22:23.060 --> 22:25.860]  that connects to a server, it gets this response, it's
[22:25.860 --> 22:29.180]  configured to use DartTLS, then we kind of have
[22:29.320 --> 22:31.160]  a contradiction here. Like this is
[22:31.980 --> 22:34.640]  kind of a logical inconsistency in the standard.
[22:35.280 --> 22:38.640]  The standard doesn't really say anything about this.
[22:38.640 --> 22:41.080]  This is just where the standard
[22:41.080 --> 22:43.400]  has an internal conflict.
[22:45.400 --> 22:45.500]  And
[22:47.520 --> 22:49.980]  after all, the only reasonable way
[22:49.980 --> 22:53.000]  for a client to react to this is to just
[22:53.000 --> 22:56.160]  terminate the connection, because it cannot do DartTLS
[22:56.160 --> 22:57.800]  in this situation.
[22:59.360 --> 23:02.100]  So there's no way to secure this connection
[23:02.100 --> 23:05.000]  and if it's configured to have a secure connection,
[23:05.000 --> 23:07.900]  it should just not accept this.
[23:09.820 --> 23:10.840]  Now,
[23:10.840 --> 23:13.980]  not surprisingly, some clients will allow pre-auth
[23:13.980 --> 23:17.020]  connection and then just don't do DartTLS because
[23:17.020 --> 23:18.500]  they can't.
[23:19.160 --> 23:22.920]  And this is also a security flaw.
[23:22.920 --> 23:25.780]  You also obviously can do mailbox content spoofing,
[23:25.780 --> 23:29.100]  like you're a network attacker person in the middle
[23:29.100 --> 23:31.900]  and then client connects, you send this pre-auth
[23:31.900 --> 23:34.740]  response and then you're kind of the upstream server
[23:34.740 --> 23:37.860]  for that client. So you cannot steal credentials because
[23:37.860 --> 23:40.780]  the client is already authenticated, but
[23:40.780 --> 23:44.140]  you can forge the content
[23:44.140 --> 23:47.280]  of the inbox. And also, you can sometimes steal
[23:47.280 --> 23:50.460]  mail, for example, if you're using IMAP
[23:50.460 --> 23:52.940]  then usually a sent mail is stored in the
[23:52.940 --> 23:56.200]  send folder, so that you can steal. And some clients
[23:56.200 --> 23:59.040]  also, when they connect to an IMAP server, they start
[23:59.040 --> 24:01.640]  synchronizing folders, so
[24:01.640 --> 24:04.880]  there you may be able to steal mailbox content.
[24:07.680 --> 24:08.240]  Then
[24:08.240 --> 24:10.920]  there's an IMAP feature which is called mailbox
[24:10.920 --> 24:13.960]  referrals. And the idea here is that
[24:13.960 --> 24:16.960]  the server can tell a client that it should use another
[24:16.960 --> 24:19.740]  server. So it's something like a forward
[24:19.740 --> 24:23.100]  feature, where a server can say, yeah,
[24:23.100 --> 24:25.960]  like I'm forwarding you to this other server if you want
[24:25.960 --> 24:27.540]  to access this mailbox.
[24:29.580 --> 24:31.920]  And now the interesting thing is
[24:31.920 --> 24:34.900]  if you combine these two things, you have this pre-auth, which
[24:34.900 --> 24:37.860]  means you can prevent the client from starting a TLS
[24:37.860 --> 24:40.800]  connection. And then you can do this referral, which
[24:40.800 --> 24:43.840]  refers the client to another server. And this
[24:43.840 --> 24:46.080]  can be our attacker server. So
[24:46.080 --> 24:49.820]  we prevent the TLS connection from happening as an
[24:49.820 --> 24:52.820]  attacker. Then we forward the user to a server
[24:52.820 --> 24:55.960]  and we control that server. So this can have
[24:55.960 --> 24:58.840]  TLS and the client logs in. And then
[24:58.840 --> 25:01.880]  we have the client's credentials. So this is also
[25:02.020 --> 25:03.480]  a pretty severe attack.
[25:05.100 --> 25:06.800]  We have to say here that
[25:06.800 --> 25:09.960]  this mailbox referrals feature, and there's a similar
[25:09.960 --> 25:12.880]  feature called login referrals, these are not widely
[25:12.880 --> 25:15.760]  supported. So we only found one
[25:15.760 --> 25:18.780]  mail client where we could perform this attack. This was
[25:18.940 --> 25:21.740]  a mail client called Alpine. So most
[25:21.740 --> 25:24.560]  mail clients, they just don't support these features, so they are not
[25:24.560 --> 25:28.080]  affected by this. But still
[25:28.080 --> 25:30.940]  it shows kind of that there are features in IMAP
[25:30.940 --> 25:33.800]  where it's not really thought through what that
[25:33.800 --> 25:36.840]  means in combination with StartTLS.
[25:38.540 --> 25:39.880]  So yeah,
[25:39.880 --> 25:43.040]  to summarize that, so StartTLS
[25:43.040 --> 25:45.960]  has a systemic problem with buffering bugs. They can
[25:45.960 --> 25:49.080]  appear both on the server and the client sites. There
[25:49.080 --> 25:51.760]  are several features in IMAP that are problematic
[25:51.760 --> 25:55.960]  or insecure if you combine them with StartTLS.
[25:56.020 --> 25:57.800]  And also StartTLS does not
[25:57.800 --> 26:00.720]  really provide any security advantage over
[26:00.720 --> 26:03.560]  normal implicit TLS connection.
[26:04.640 --> 26:06.960]  So our conclusion is you should
[26:06.960 --> 26:09.940]  not use StartTLS for mail connections, for
[26:09.940 --> 26:12.420]  email client connections, I guess. So
[26:14.160 --> 26:15.640]  if you are
[26:15.640 --> 26:18.780]  using email, which I guess most of you do, and if you're using
[26:18.940 --> 26:21.820]  a mail client, then you should change
[26:21.820 --> 26:24.880]  its configuration to use the implicit TLS
[26:24.880 --> 26:27.460]  pods and not to use StartTLS.
[26:28.000 --> 26:30.820]  And then you will not be affected by most of these
[26:30.820 --> 26:34.060]  attacks. Some can still happen, but because some
[26:34.060 --> 26:37.020]  it's enough when the server is supporting StartTLS,
[26:37.020 --> 26:39.580]  but most of these attacks will be prevented.
[26:41.180 --> 26:42.880]  If you run a mail server,
[26:42.880 --> 26:45.720]  you should definitely make sure that you support
[26:45.720 --> 26:48.780]  implicit TLS. I mean, there's
[26:48.780 --> 26:51.580]  an RFC that says that you should use the implicit
[26:51.580 --> 26:55.620]  TLS pods, but there are, for example,
[26:55.620 --> 26:57.960]  the Microsoft SMTP
[26:57.960 --> 27:00.780]  servers, they don't support implicit TLS
[27:00.780 --> 27:03.800]  for SMTP. And if
[27:03.800 --> 27:06.620]  you can, then disable StartTLS. Now
[27:06.620 --> 27:09.980]  we are aware that this is not an easy thing,
[27:09.980 --> 27:12.880]  particularly if you have existing customers. Like if you have
[27:12.880 --> 27:15.640]  an existing user base, then telling them,
[27:15.640 --> 27:18.820]  yeah, sorry, half of your mail configurations will
[27:18.820 --> 27:21.680]  break next week, that's a tough thing to do.
[27:21.740 --> 27:24.900]  So I'll say it would be ideal to just disable it
[27:24.900 --> 27:27.360]  on the server, but this
[27:28.040 --> 27:30.800]  is probably not feasible for people
[27:30.800 --> 27:33.260]  who have existing user bases. But if you
[27:33.900 --> 27:36.820]  start like a new mail server setting, then
[27:36.820 --> 27:40.080]  you can start right away without StartTLS.
[27:43.020 --> 27:43.620]  So
[27:43.620 --> 27:46.360]  then I want to talk a bit about the special case,
[27:46.360 --> 27:49.020]  the server-to-server or MTA-to-MTA
[27:49.020 --> 27:52.280]  connection. In case you don't know, MTA stands
[27:52.280 --> 27:55.960]  for Mail Transfer Agent, which is another word for mail server.
[27:57.800 --> 27:58.320]  So
[27:58.320 --> 28:00.780]  this situation there is a bit different.
[28:01.380 --> 28:04.360]  For one, there's currently no way to use implicit
[28:04.360 --> 28:07.220]  TLS on MTA-to-MTA connections.
[28:07.220 --> 28:10.160]  That's just not part of the standards. There's no
[28:10.160 --> 28:12.140]  RFC how to do this.
[28:12.140 --> 28:12.880]  And
[28:15.080 --> 28:17.800]  it would not be easy to
[28:17.800 --> 28:19.940]  implement that.
[28:20.700 --> 28:24.460]  And also, traditionally, the server-to-server
[28:24.460 --> 28:27.720]  connections are purely opportunistic.
[28:27.720 --> 28:30.380]  So usually mail server doesn't validate a certificate
[28:30.380 --> 28:33.160]  because also usually the certificate host is
[28:33.160 --> 28:36.440]  not the host of the email address. So even validating
[28:36.440 --> 28:39.520]  the set doesn't make much sense. And you usually
[28:39.520 --> 28:42.500]  don't have an expectation against active attackers.
[28:43.060 --> 28:44.720]  Now, this is
[28:45.480 --> 28:48.000]  changing a bit. So there are two standards
[28:48.560 --> 28:51.360]  that one is based on DNSSEC and called DAIN
[28:51.360 --> 28:55.080]  and the other is called MTA-STS, which is kind of a
[28:55.080 --> 28:57.520]  trust on first use kind of mechanism
[28:58.120 --> 29:00.960]  that are trying to secure these server-to-server
[29:00.960 --> 29:04.100]  connections. It would be a different
[29:04.100 --> 29:06.660]  talk to talk about the advantages and disadvantages of
[29:06.660 --> 29:10.340]  those. My personal opinion is that MTA-STS
[29:10.340 --> 29:12.620]  is the more promising
[29:12.620 --> 29:16.320]  mechanism, but that's a
[29:16.320 --> 29:20.540]  controversial discussion. Let's just put it like this.
[29:20.540 --> 29:21.660]  But so
[29:23.300 --> 29:25.420]  yeah, it would be challenging
[29:25.420 --> 29:28.100]  to introduce an implicit TLS mode into
[29:28.100 --> 29:31.160]  MTA-to-MTA connections. Like right now,
[29:31.160 --> 29:33.600]  we are just using star TLS. Even if we use this
[29:33.600 --> 29:36.740]  advanced mechanism, we are still using star TLS.
[29:37.160 --> 29:38.960]  And the problem here is like that
[29:39.980 --> 29:42.700]  we have a lot of compatibility issues here.
[29:42.700 --> 29:45.680]  Like in email, it's a very old
[29:45.680 --> 29:47.880]  protocol and things are very established and
[29:48.500 --> 29:51.620]  probably a lot of mail servers have a firewall
[29:51.620 --> 29:54.860]  that they don't allow other ports than port 25.
[29:54.880 --> 29:57.640]  So it would be very challenging to
[29:57.640 --> 30:01.240]  change the protocol to support an implicit TLS mode.
[30:01.240 --> 30:04.400]  So I don't see that happening anytime soon.
[30:05.780 --> 30:07.480]  So if we want to secure
[30:07.480 --> 30:10.300]  these MTA-to-MTA connections, like if we talk about
[30:10.300 --> 30:13.140]  something like MTA-STS, then we should really
[30:13.140 --> 30:16.080]  need to make sure that we fix these buffering
[30:16.080 --> 30:19.240]  bugs, like these command injection and response injection
[30:19.240 --> 30:21.020]  that I've talked about earlier.
[30:22.320 --> 30:25.360]  If you think that you want to secure
[30:25.360 --> 30:28.420]  these server-to-server connections, then you also need to think about this.
[30:30.120 --> 30:32.560]  And you need to basically audit the implementation
[30:32.560 --> 30:34.760]  so they don't have these bugs.
[30:36.560 --> 30:38.740]  Then just quickly also
[30:38.740 --> 30:41.600]  start TLS is used in many other protocols like
[30:41.600 --> 30:44.560]  XMPP, FTP, then managed
[30:44.560 --> 30:47.320]  sieve, which is a mail filtering thing, then
[30:47.320 --> 30:51.100]  LDAP, MySQL, NNTP.
[30:51.600 --> 30:53.640]  And I guess
[30:53.640 --> 30:55.780]  this is obvious, but the
[30:56.480 --> 31:00.200]  kind of bugs that we found, they can be present
[31:00.200 --> 31:03.360]  in implementations of all protocols that support
[31:03.360 --> 31:06.000]  start TLS or something like start TLS.
[31:06.640 --> 31:08.840]  So there's lots of potential for
[31:08.840 --> 31:11.720]  future research here. Like this is something that
[31:11.720 --> 31:14.960]  should be tested in more settings.
[31:18.560 --> 31:21.980]  And also our general recommendation
[31:21.980 --> 31:25.020]  that if you have a choice between
[31:25.020 --> 31:27.960]  start TLS and implicit TLS, then you should prefer
[31:27.960 --> 31:29.340]  implicit TLS. And
[31:31.340 --> 31:34.060]  for future protocols, maybe you should
[31:34.060 --> 31:37.140]  just only support implicit TLS.
[31:38.240 --> 31:39.220]  And then
[31:40.020 --> 31:42.840]  something that is kind of not
[31:42.840 --> 31:46.100]  on the security side, but we can also ask what about
[31:46.100 --> 31:48.560]  performance? What about speed?
[31:49.940 --> 31:50.580]  Because
[31:50.580 --> 31:54.300]  I don't know. I come from Germany and
[31:54.300 --> 31:57.660]  Germany is known for having pretty bad mobile Internet.
[31:57.780 --> 32:00.620]  Not sure if you're aware of that, but if you ever go to Germany,
[32:00.620 --> 32:02.820]  that's what you will experience. So
[32:03.320 --> 32:07.240]  if you try to send an email with a bad Internet connection,
[32:07.240 --> 32:09.780]  it's pretty annoying. Like you have these things that
[32:10.400 --> 32:13.140]  you may get a connection error or the
[32:13.140 --> 32:15.720]  email may be sent, but it's not stored in your
[32:15.720 --> 32:19.020]  send folder because these are two different connections.
[32:19.020 --> 32:22.100]  So having a better performance here is good
[32:22.100 --> 32:24.960]  and also more reliability. If we need
[32:24.960 --> 32:28.180]  fewer connection roundtrips, then it's more
[32:28.180 --> 32:29.220]  reliable.
[32:30.720 --> 32:34.100]  This I also find interesting. There's been a lot of effort
[32:34.100 --> 32:36.580]  to reduce roundtrips in TLS.
[32:36.820 --> 32:39.720]  In TLS 1.3, by design,
[32:39.720 --> 32:42.980]  if you make a new connection, it has one roundtrip less
[32:42.980 --> 32:46.140]  than older TLS versions. And there's also
[32:46.320 --> 32:49.140]  a zero RTT mode, which is kind of...
[32:50.360 --> 32:52.340]  there are some security concerns
[32:52.340 --> 32:55.300]  about this, but the TLS community has decided that
[32:55.300 --> 32:58.620]  they still want to do this despite these security concerns.
[32:58.920 --> 33:01.280]  And I find this interesting that so much effort has been put
[33:01.280 --> 33:04.200]  into reducing TLS roundtrips, but it seems nobody has
[33:04.200 --> 33:07.340]  tried to optimize email protocols the same way.
[33:08.820 --> 33:10.320]  And if we look at
[33:10.320 --> 33:13.040]  startTLS, then all the information that is
[33:13.040 --> 33:16.080]  exchanged before we do startTLS is kind of
[33:16.080 --> 33:19.220]  meaningless, because we cannot
[33:19.220 --> 33:22.080]  trust it anyway, so we need to retransmit everything
[33:22.080 --> 33:24.940]  after the TLS handshake anyway. So for example,
[33:24.940 --> 33:27.820]  the server capabilities, you're
[33:27.820 --> 33:30.720]  always getting them again after the handshake.
[33:30.740 --> 33:33.960]  So you can think about this, that everything that is happening
[33:33.960 --> 33:37.440]  before we do this handshake, it is just wasted.
[33:37.440 --> 33:39.360]  It doesn't have any meaning.
[33:39.360 --> 33:42.800]  So this kind of
[33:42.800 --> 33:45.660]  directly leads to that if you use startTLS,
[33:45.660 --> 33:48.440]  you need more roundtrips. It depends on the protocol
[33:48.440 --> 33:51.480]  and also a bit depends on the implementation, but
[33:51.480 --> 33:54.240]  it's usually two or three roundtrips more than if you
[33:54.240 --> 33:56.580]  directly use implicit TLS.
[33:57.300 --> 34:00.300]  So avoiding startTLS
[34:00.300 --> 34:03.300]  is not just more secure, it's also just faster.
[34:03.300 --> 34:05.220]  Which is, I guess, good.
[34:05.220 --> 34:08.780]  And there are some other ways.
[34:08.780 --> 34:12.260]  This is kind of now going a bit into other topics,
[34:12.260 --> 34:14.460]  but there are other easy ways to improve
[34:14.460 --> 34:16.880]  email protocol roundtrips.
[34:17.980 --> 34:20.600]  So email authentication uses something
[34:20.600 --> 34:21.720]  called Zazzle.
[34:23.460 --> 34:26.620]  Zazzle is an authentication framework that is used
[34:26.620 --> 34:29.180]  in all three email protocols.
[34:29.900 --> 34:32.540]  And it's kind of an abstraction of different authentication
[34:32.540 --> 34:35.480]  methods. Although most of the time everyone uses
[34:35.480 --> 34:38.900]  username and password, but there are different authentication methods.
[34:39.960 --> 34:42.020]  And if you look at this, how this looks like
[34:42.020 --> 34:44.640]  in IMAP, we can have something like the above,
[34:44.640 --> 34:47.580]  where we have an authenticate plane and then
[34:47.580 --> 34:50.900]  we have some Base64. And this Base64,
[34:50.900 --> 34:53.640]  it is basically, it's a zero byte, then a username,
[34:53.640 --> 34:55.600]  then another zero byte and a password.
[34:56.800 --> 34:59.680]  And that is our login. So this is one
[34:59.680 --> 35:03.060]  roundtrip to login. And we can have this
[35:03.060 --> 35:06.360]  thing below where we have authenticate login,
[35:06.360 --> 35:07.940]  then we have a new line.
[35:08.080 --> 35:11.960]  So this is kind of optional. We can, in this authenticate
[35:11.960 --> 35:14.780]  line, we can already send data or we can
[35:14.780 --> 35:15.800]  just not.
[35:17.740 --> 35:20.660]  And then the server asks for a username.
[35:20.660 --> 35:24.020]  This is also Base64 encoded and asks for a password.
[35:24.480 --> 35:26.500]  So this is three roundtrips.
[35:26.500 --> 35:28.800]  So there's quite some difference here and
[35:29.880 --> 35:32.800]  it's quite varying what will happen depending
[35:32.800 --> 35:36.120]  on what client and server configuration you use.
[35:37.080 --> 35:38.740]  So the first thing is that IMAP
[35:38.740 --> 35:41.820]  has a feature called SASL IR, which basically
[35:41.820 --> 35:44.820]  means you can initiate an authentication right away
[35:44.820 --> 35:47.600]  with data. So this is the thing that you have this
[35:48.180 --> 35:50.540]  authenticate plane and send something in the same line
[35:52.280 --> 35:54.940]  where... or you can also not do that.
[35:54.940 --> 35:58.060]  And of course, this is faster. This saves you a roundtrip if you can
[35:58.060 --> 36:00.820]  send data right away with the authentication
[36:00.820 --> 36:01.880]  command.
[36:03.520 --> 36:06.920]  And also, Zazzle has two different modes for
[36:06.920 --> 36:09.860]  username password authentication. They are called plain
[36:09.860 --> 36:10.960]  and login.
[36:13.120 --> 36:15.880]  To make matters even more complicated, both
[36:15.880 --> 36:19.260]  POP3 and IMAP, they have a built-in authentication
[36:19.260 --> 36:22.200]  that is not part of Zazzle, which is kind of
[36:22.200 --> 36:25.660]  part of their protocol itself. In IMAP,
[36:25.660 --> 36:28.760]  this has one roundtrip. In POP3, it has
[36:28.760 --> 36:30.140]  two roundtrips.
[36:32.760 --> 36:34.880]  So this login method,
[36:34.880 --> 36:37.240]  this is not standardized and
[36:37.240 --> 36:40.780]  it is also declared obsolete by the IANA.
[36:40.780 --> 36:43.200]  So the IANA has a registry of
[36:43.760 --> 36:46.360]  Zazzle authentication methods and there it's declared as
[36:46.360 --> 36:49.320]  obsolete. And what it basically does is
[36:49.320 --> 36:52.320]  it sends the username and the password base64 encoded
[36:52.320 --> 36:55.980]  in two roundtrips or just two lines in other words.
[36:56.760 --> 36:58.600]  And then there's this plain authentication
[36:58.600 --> 37:01.580]  method, which is a standard and it sends
[37:01.580 --> 37:04.680]  username and password encoded in one roundtrip.
[37:04.780 --> 37:07.280]  So you save another roundtrip here.
[37:09.360 --> 37:09.960]  So
[37:10.680 --> 37:13.680]  the plain method is standardized and it's
[37:13.680 --> 37:16.600]  faster than login. So it's clearly the better
[37:16.600 --> 37:20.440]  method. And from the security, it doesn't really matter.
[37:20.980 --> 37:22.660]  It's a normal username and password
[37:22.660 --> 37:25.600]  authentication. There's nothing fancy about it.
[37:27.340 --> 37:28.840]  So almost everyone
[37:28.840 --> 37:31.960]  supports both, like both servers and clients, but
[37:31.960 --> 37:34.860]  there's not really a reason to support login.
[37:36.120 --> 37:37.680]  So if you want to
[37:37.680 --> 37:40.720]  have faster email, then you should
[37:40.720 --> 37:43.760]  use implicit TLS and not start TLS. You should support
[37:43.760 --> 37:47.620]  the sessil-ir, which is specifically in IMAP.
[37:47.760 --> 37:50.140]  And you should disable the sessil-login
[37:50.140 --> 37:53.120]  method. Like for example, I figured out my own
[37:53.120 --> 37:56.140]  mail server, it supported both. And my client,
[37:56.140 --> 37:58.760]  if it supported both, it used login because
[37:58.760 --> 38:01.060]  that was the first in the client.
[38:01.680 --> 38:04.900]  It's in class mail. It's the first method that it
[38:04.900 --> 38:07.940]  supports. So it's slower for
[38:07.940 --> 38:10.880]  no gain. And I disabled it on the server and
[38:10.880 --> 38:12.120]  now I'm saving.
[38:14.940 --> 38:16.460]  So yeah.
[38:17.020 --> 38:19.200]  Yeah, that was it.
[38:19.920 --> 38:23.180]  Yeah, don't use TLS. Thanks for listening
[38:23.180 --> 38:26.960]  and I guess we have some time for Q&A now.
[38:31.040 --> 38:31.980]  Hold on.
[38:31.980 --> 38:33.760]  Welcome back, everybody.
[38:35.120 --> 38:37.900]  Can you, Hanno, can you unshare your screen
[38:37.900 --> 38:40.280]  maybe so we can just see you?
[38:40.280 --> 38:43.360]  I just want to put my background on.
[38:47.070 --> 38:48.070]  Okay.
[38:48.790 --> 38:51.650]  So we have, I think we have three questions for you.
[38:51.650 --> 38:52.990]  Can you hear me?
[38:53.770 --> 38:58.010]  Okay. So is the implication
[38:58.010 --> 39:01.050]  that the clients in the SMTP case for ease
[39:01.050 --> 39:03.950]  just ignore responses from the server? I expect
[39:03.950 --> 39:06.990]  them to be a state machine that says, wait, what?
[39:06.990 --> 39:09.970]  I haven't started sending them yet. What do you mean?
[39:11.250 --> 39:13.270]  No, that's not the implication.
[39:13.270 --> 39:16.210]  So the client is not ignoring these answers, but it is
[39:16.750 --> 39:19.110]  like it is processing these line
[39:19.110 --> 39:22.190]  by line. So it is sending
[39:22.410 --> 39:25.090]  a command to the server and then it's reading a line from the server
[39:25.090 --> 39:28.210]  and processing that. And that is why if you do this
[39:28.210 --> 39:31.170]  attack, you kind of have to inject all the
[39:31.170 --> 39:34.330]  commands that the client will send so it will get
[39:34.330 --> 39:36.610]  the answers that it expects.
[39:37.750 --> 39:41.230]  Is this understandable? I hope so.
[39:41.870 --> 39:43.690]  We are monitoring the discord.
[39:43.690 --> 39:47.330]  So if they reply back, I can do it.
[39:47.590 --> 39:48.170]  Yeah.
[39:50.350 --> 39:52.750]  Actually, give me one second. I think we are going to try
[39:52.750 --> 39:55.930]  and share the slides with you so everyone can see it.
[39:58.300 --> 40:00.040]  Give me one second.
[40:00.160 --> 40:02.320]  Share this. I did that.
[40:05.140 --> 40:06.340]  Sorry, everybody.
[40:06.340 --> 40:07.520]  Let's see.
[40:14.680 --> 40:17.020]  So they want me to... let's see.
[40:24.690 --> 40:26.150]  I know we have dead air.
[40:29.340 --> 40:31.700]  Let's see if I can share the screen.
[40:31.820 --> 40:34.400]  I am now also in the discord.
[40:35.240 --> 40:36.480]  That's okay.
[40:36.480 --> 40:39.740]  I will be able to see questions later if they are.
[40:51.180 --> 40:53.300]  I see your screen now.
[40:53.480 --> 40:54.420]  Okay.
[41:10.290 --> 41:19.070]  The second question I have,
[41:19.070 --> 41:21.270]  in the context of SMTP,
[41:21.270 --> 41:24.550]  do you see MTA STS having positive,
[41:24.550 --> 41:27.850]  negative, no change to the start TLS risks?
[41:31.010 --> 41:32.530]  It doesn't...
[41:34.510 --> 41:36.090]  I think the question
[41:36.090 --> 41:37.650]  is framing it wrong.
[41:37.650 --> 41:39.230]  The thing is,
[41:40.550 --> 41:43.550]  MTA STS is introducing an expectation
[41:43.550 --> 41:45.890]  that we didn't have previously.
[41:45.890 --> 41:49.530]  That is that these connections are secure against active attackers.
[41:49.910 --> 41:53.230]  And these attacks can compromise this expectation.
[41:53.670 --> 41:55.510]  So before, we could say these attacks
[41:55.510 --> 41:57.370]  don't matter for MTA to MTA
[41:57.370 --> 42:00.930]  because we don't expect it to be secure anyway.
[42:00.990 --> 42:05.430]  And now we want to introduce connection security for that.
[42:05.650 --> 42:07.750]  So now we have to care about these attacks.
[42:07.750 --> 42:10.570]  But it doesn't really change the risk.
[42:10.570 --> 42:14.030]  It's just that what we try to achieve with MTA STS
[42:14.030 --> 42:16.670]  that is compromised if we have these vulnerabilities.
[42:19.010 --> 42:20.710]  Does that make sense?
[42:21.270 --> 42:22.350]  I mean...
[42:23.350 --> 42:25.130]  Yes, I understand it.
[42:25.710 --> 42:27.830]  Again, we can be in the Slack Discord
[42:28.350 --> 42:31.330]  and maybe later, if people have more questions,
[42:31.330 --> 42:32.850]  you can join in there.
[42:33.570 --> 42:34.890]  Last one that I have.
[42:34.890 --> 42:38.530]  In what kind of issues does the speaker see with implicit TLS?
[42:41.070 --> 42:45.130]  So I think if you compare start TLS and implicit TLS,
[42:45.130 --> 42:48.970]  there are no added issues by implicit TLS.
[42:49.010 --> 42:51.550]  Because it's just the simpler thing.
[42:51.870 --> 42:53.510]  Like with start TLS,
[42:53.510 --> 42:56.810]  we start in plain text and then we do a state transition
[42:56.810 --> 43:00.610]  and that introduces potential for errors.
[43:00.610 --> 43:03.630]  And with implicit TLS, we just don't have that.
[43:03.630 --> 43:06.810]  So I don't see any risk in implicit TLS
[43:06.810 --> 43:09.790]  that you wouldn't have with start TLS.
[43:10.050 --> 43:12.750]  Of course, it has all the risks that you can have
[43:12.750 --> 43:14.550]  otherwise with TLS.
[43:16.030 --> 43:18.310]  If there's a bad implementation,
[43:18.310 --> 43:22.810]  if there's bad randomness or vulnerable algorithms,
[43:22.810 --> 43:24.110]  then you have all the same risks.
[43:24.110 --> 43:27.150]  But you would have the same risks with start TLS as well.
[43:28.250 --> 43:30.510]  We're getting another question.
[43:30.510 --> 43:34.090]  Any thoughts on Telnet start TLS?
[43:35.150 --> 43:37.450]  I have no idea, sorry.
[43:37.710 --> 43:39.450]  I have seen that it exists,
[43:39.450 --> 43:43.550]  but I'm not sure if anyone is using that.
[43:43.650 --> 43:45.910]  I would be curious if anyone is using that.
[43:45.910 --> 43:51.110]  I feel that people use SSH there usually.
[43:52.030 --> 43:55.130]  And then our final question,
[43:55.130 --> 43:56.890]  just thanking you for the talk.
[43:56.890 --> 43:59.850]  Is anyone working on email POP3 replacements
[43:59.850 --> 44:01.610]  with something more secure?
[44:05.410 --> 44:06.530]  I'm not sure.
[44:06.530 --> 44:09.150]  There's not really a problem with POP3.
[44:09.570 --> 44:13.190]  This is not the issue of the talk,
[44:13.190 --> 44:15.390]  but I feel POP3 is a really simple protocol
[44:15.390 --> 44:17.330]  and I kind of like that.
[44:18.150 --> 44:20.170]  I'm also one of these weird people
[44:20.170 --> 44:22.510]  that I'm still using POP3.
[44:22.510 --> 44:25.450]  I like to have the mails on my laptop locally.
[44:30.770 --> 44:34.170]  If you use it with TLS, then it's a fine protocol.
[44:35.570 --> 44:36.690]  Well, again,
[44:36.690 --> 44:39.270]  we would like to thank you for your talk.
[44:40.050 --> 44:42.830]  If anybody has any more questions,
[44:42.830 --> 44:44.410]  you can hang out in the Discord.
[44:45.130 --> 44:48.790]  We'll try and relate them to you, anything like that.
[44:48.790 --> 44:51.010]  I want to thank everyone who's watching the live stream
[44:51.010 --> 44:55.170]  for sitting with us through the first ever
[44:55.170 --> 44:59.090]  DEF CON Safe Mode and the Glitch Crypto and Privacy Village.
[44:59.090 --> 45:01.110]  I want to remind everyone again that we have
[45:01.110 --> 45:03.910]  the Gold Bug Challenge that's still there.
[45:04.170 --> 45:06.550]  And I would like to, again, thank you for your talk
[45:06.550 --> 45:09.930]  and I hope you enjoyed yourself.
[45:12.660 --> 45:14.120]  I guess we wait.
[45:17.000 --> 45:19.960]  Okay, I can leave here now?
